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In the European project SOCRATES?®, eleven public and private organisations have been 
challenged to try different ways of working together to realise smart traffic and navigation 
services. The partners have selected and developed three types of services, which will be 
tested by 9,000 users in the regions of Amsterdam, Antwerp, Copenhagen and Munich. 
These services include smart route advice (for example in case of events), actual speed 
and lane advice, and local warnings (for example on environmental zones and road 
works). The pilots will take place in 2019 and 2020 and include motorways, regional roads, 
urban-interurban interfaces and urban roads. It is expected to lead to more business 
opportunities for the private partners, a more cost-effective traffic management for the 
public authorities and better service for the road users. 


The SOCRATES? main learning objectives are to gain insights on how to organise the 
collaboration between public and private parties, and what key elements are necessary to 
assure scalability and success of use cases. 


1.1 SOCRATES”? in nine activities 


The SOCRATES? project consists of nine activities and follows a V-model approach. First, 
a common framework was defined (Activity 2), which was then specified for the four 
pilots (Activity 3). This report is the reflection of Activity 3. The designs will be validated 
in the pilots (Activity 4-7), evaluated (Activity 8) and the results will be used to update the 
framework (Activity 9). 


CEF call on ITS Public policies and business strategies 


Activity 1: Project management 


Activity 2: Integrated traffic Activity 9: 
management framework Consolidation 


Activity 3: Common designs Activity 8: 
and specifications Evaluation 


Activity 4, 5, 6 and 7 Pilots in the regions of: 
Amsterdam - Antwerp - Copenhagen - Munich 





Figure 1: V-model approach. 


1.2 What’s new in SOCRATES??? 


SOCRATES?° works as much as possible with existing techniques to realise smart traffic 
services and traffic management. So, what's new? To create these better services for 
road users, all parties involved - international service providers, car manufacturers, ITS 
companies and road authorities - should cooperate and share information. The partners 
in SOCRATES? are defining and experiencing sustainable public-private cooperation 

and business cases in traffic management. This is an important step in the direction of 
implementation of smart mobility services. 


The collaboration makes SOCRATES?* a unique and valuable project, from which lessons 
can be drawn for all stakeholders in the traffic management chain. It is expected that 
SOCRATES? will learn from different approaches. 





1.3 SOCRATES?” framework on public-private traffic management 


The needs and interests, both for the commercial parties (e.g. revenues, customer 
satisfaction) as well as authorities (fast, safe and green traffic), are evident. They are in 
some extent overlapping but are different on other aspects, and it may be a challenge to 
find a cooperation model that is attractive for all. That is why the SOCRATES? partners 
started with defining a common ground for cooperation on a strategic level, the so-called 
SOCRATES?! framework on public-private traffic management. The elaboration of different 
models for cooperation was mainly covered in SOCRATES? Activity 2. 


1.4 SOCRATES?” vision 


The vision of the SOCRATES?! partners is that cooperation will lead to a win-win-win 
situation for all actors in the traffic management eco-system: the road user, the road 
operator (Traffic Management Centres) and service providers. To reach the win-win-win 
situation, some basic concepts and common agreements were elaborated. 


The partners in SOCRATES?* wanted to establish something new and not just to improve an 
existing concept of cooperation. To do so, they recognised that a paradigm shift should be 
made from ‘managing and influencing traffic’ to ‘supporting people on their travel from A 
to B’. To bring this vision to the pilots in the ongoing deployment work, two statements are 
adopted as the agreed base: 


e Active involvement of the customer (road user) and the communities, pre-trip, on-trip 
and post-trip 
e Move from managing traffic to supporting individuals 


As a result, the vision does not just focus on technology or the traffic management process 
but is elaborated along four elements: customer, community, technology and cooperation. 


The essence of each element is captured into four ‘slogans’, summarizing what is new 
behind this concept, compared to contemporary traffic management. See Figure 2. 
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Figure 2: The four elements of SOCRATES? and their slogans. 





1.5 Reading guide 


The goal of Activity 2 was to develop an optimal framework for cooperation between the 
public and private partners, as a basis for a European deployment of interactive traffic 
management. As a result, a theoretical framework was created, describing options for 
cooperation on a strategic level. 

Activity 3 covered the tactical level by specifying the framework for the four pilots. This 
report describes the approach and the results of Activity 3. 


Chapter 2 introduces a guideline for stakeholders engaged in (similar) deployment projects 
for interactive traffic management. Chapters 3-6 describe the sub-steps to take when 

it comes to preparing pilot deployments. These sub-steps form the milestones of the 
mentioned guideline. Chapter 7 concludes on the results of Activity 3 of the SOCRATES?° 
project and gives an outlook on activities 4-7. 


2. SETTING THE STAGE FOR THE 
DEPLOYMENT OF INTERACTIVE 
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Before the individual pilots could be further specified, some common agreements had 
to be made on a tactical level. This included an explicit concept for interactive traffic 
management, eventually resulting in functional designs for each envisioned pilot site and 
use case. 


Such a concept is an important base when preparing pilot deployments. This way, a 
common understanding on how a pilot site is deployed can be gained, considering both 
(a) a common mission and vision, as elaborated in Activity 2, and (b) the individual 
realisation of each pilot site and each use case, as elaborated in Activities 4, 5, 6 and 7. 
The concept includes some organisational, functional and technical aspects, touching on 
the roles of partners and their products and services, as well as the interfaces between 
those products and services. 


We believe that a coordinated elaboration of these aspects leads to successful cooperation 
deployments, not only in the SOCRATES?” pilots, but in any comparable project. This way, 
the outcomes of Activity 3 can be seen as a guideline for stakeholders engaged in (similar) 
deployment projects. 


The mentioned aspects have been elaborated in dedicated Focus Groups within Activity 3. 
As an outcome from these Focus Groups, some sub-steps could be identified when 

it comes to preparing pilot deployments. The sub-steps form the milestones of the 
mentioned guideline. They are introduced below and are described in more detail in the 
subsequent text chapters: 


e Make an inventory of the pilot site 
= Describe local prerequisites and conditions 
= Identify individual partner assets in terms of data availability, existing management 
strategies etc. 
> See 'Pilot site inventory’, chapter 3.1 


e Select a use case 
a Decide which use case is deployed at which pilot site 
a Discuss what is useful and feasible in the particular context 
> See 'Use cases per pilot site’, chapter 3.2 


e Specify a cooperation model 
= Explore concepts, characteristics and ambitions of different cooperation models 
a Assign a suitable type of a cooperation model to each pilot deployment 
> See 'Cooperation models’, chapter 3.3 


e Specify an intermediary 
= Explore potential functions and roles of intermediaries 
a Assign a suitable type of an intermediary to each pilot deployment 
> See ‘Intermediary design’, chapter 3.4 


e Specify a data interface (TMex) 
= Define a concept to exchange data between different parties, including potential data 
protocols and data platforms 
= Explore requirements, prerequisites (such as existing data standards) and technical 
solutions for such an interface 
> See "Specification of data interface', chapter 4 


e Provide a functional design 
= Describe a functional architecture for each pilot deployment 
m Identify system functions and their interactions 
> See 'Pilot Designs', chapter 5 


e Plan the evaluation 
= Describe evaluation goals 
= Define research questions and analysis methods 
> See 'Evaluation', chapter 6 
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Figure 3: Preliminary step-by-step plan to the deployment of interactive traffic management. 


3. BASICS FOR THE PILOT DESIGNS 











3.1 Pilot site inventory 


It is important to get familiar with the different characteristics of each pilot site, to adapt 
the pilot deployment to local conditions and constraints. To have an overview on these 
conditions, a survey was initiated among pilot site partners, asking the following questions: 


e What is the geographic boundary of the pilot site and which roads should be part of the 
use case in pilot site? 

e What are the current problems at the pilot site network in relation to the services in the 
use case? 
Which services are deployed in the pilot site that are similar to services in the use case? 
Which partners are involved in these services? 

e Which wishes for improvement do you have in relation to the use case in the pilot site? 


The outcome of the survey was a first preparation step for the individual pilot designs. 
As an example, an important aspect for the 'Optimising network traffic flow' use case was 


the road network situation. For the Amsterdam deployment, the following map was used 
as an input. 


LEGEND 


B Highway 
B Provincial Road 
B Local Road 
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Figure 4: Road network situation overview, pilot deployment 'Optimising network traffic flow, Amsterdam". 
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Another important prerequisite for the pilots is the current availability of data. This was 
also explored by a survey, asking for the availability per pilot partner on 85 different data 
types, which have been clustered in the following seven categories: 


Dynamic Traffic/Road Status data 
Static road data 

End User/Traveller data 

Vehicle Data 

Multi-modal data 

Parking data 

Other 


Eventually, this data survey allowed a 'gap analysis', showing discrepancies between data 
required for the envisioned use cases (SOLL situation) and the actually existing data (IST 
situation). 


An example for such a gap analysis for the use case 'Optimising network traffic flow" is 
shown in Table 1. The required data sets are listed in the lines, whereas the availability 
status per pilot site is marked in the columns. The purple colored fields indicate the most 
critical data gaps, which need to be clarified within the next steps. 


Amsterdam Copenhagen Munich Antwerp 


EEE ry O O Le zu 


Current road status: Abnormal 4 1 
traffic, Incident, Hazard, Activity & m |E 
(construction, event) 


Delay Actual delays (in seconds/ 
minutes) due to abnormal traffic 


EA Current a l per road a 
EA a l 


Average | Current speed per road = = u 
traffic segment 
speed 


Current density per road = a 
segment 


a] Route of road user En] 


ll Capacity of roads (or maximum 
capacity | performance: product of 
intensity and speed) 

Location | Location of individual vehicle 
a m = m = m = 

Heading | Direction of individual vehicle 3 5 2 3 2 3 3 2 
= = | m E E En El E 

Speed Speed of individual vehicle 3 5 2 3 2 3 3 2 
[=] = | m [==] E mM En E 


Table 1: Gap analysis for data in use case 'Optimising network traffic flow. 
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3.2 Use cases per pilot site 


One of the elements of the SOCRATES?” vision is that the road user should be in the centre 
of attention. This guided the elaboration of the (sub) use cases to be deployed in the pilot 
sites Amsterdam, Antwerp, Copenhagen and Munich: 


1. Smart routing 
e Optimising network traffic flow 
e Smart destination 
2. Actual speed and lane advices 
e Lane information 
3. Local information and hazardous warnings 
e Road works warning 
e Environmental/areal information and constraints 


The selection of use cases to be tested per pilot site was done in several consecutive steps: 
e Aprovisional choice for use cases per partner at the beginning of Activity 3 

e A survey on 'preferred' use cases per partner and per pilot site 

e A final decision on use cases in a common workshop 

This way, a coordinated, common decision-making was possible, taking into account both 
individual partner perspectives (such as business interests) and overarching project goals 


(such as a complete and balanced coverage of use cases across the entire project). 


The final selection is shown below. 


PS PS 


| Optimising network traffic flow | network | Optimising network traffic flow | flow 


Smart destination —— 





Table 2: Overview of selected use cases to be tested per pilot site. 


3.3 Cooperation models 


One of the main objectives of SOCRATES?” is to design, operate and evaluate a cooperation 
framework for interactive traffic management by road authorities, service providers and 
car industries. Therefore, the project introduced and discussed different cooperation 
models and intermediary roles. A first selection of options for cooperation models and 
intermediary roles was defined in Activity 2. The next steps were to define and elaborate 
different cooperation models and intermediary roles and to determine what cooperation 
and intermediary models are applied and tested in the use cases (services) in the 
respective pilot sites. The SOCRATES?” pilots aim to experiment with different cooperation 
models and intermediary roles, to learn the effects of different options. 


Cooperation model matrix 
The cooperation models were defined in the form of a matrix, looking at three dimensions 
regarding the exchange of traffic management strategies: 


e Level of commonality: Is there a commonly agreed plan for coordinated actions or 
common insights, a so called ‘common truth’? 

e Level of detail: At what level of detail do we want/need a commonly agreed ‘truth’? 

e Level of commitment of the stakeholders: Are stakeholders free to use the agreed 
plan/basis or do they commit themselves to a set of needed actions to achieve the 
common goals? 


e No joint approach * Joint approach 
« Exchange info « Common insights 
| No coordinated services No coordinated services Coordinated services | 


Situational: Monitoring with own Share data, jointly set up Joint development CSP and 
status sensors, instruments CSP and optional improve all agree to use it 
actuators own monitoring 


Operational: Independent choice and Share actions and Joint development, choose 
actions, deployment of measures measures and optional and deploy coordinated 


measures improve own measures and | measures and actions 
actions 


Tactical: Independent development | Share approach and Joint development, choice 
approach, and choice of tactical motivation and possibly and deployment of 

TM services, approach improve own approach and | coordinated approach 
motivation motivation 


Strategical: Independent development | Share policies and prios Joint development and 
policy, priorities, and deploy of policy and possibly improve own deployment of policies 
objectives framework policy and prios 





e 1. Level of commonality 0 2. Level of detail @ 3. Level of commitment 


Table 3: Cooperation model matrix. 


As a part of defining the pilot designs the partners had a (‘bottom up”) discussion on the 
role of stakeholders and how they could cooperate. These options were elaborated with 
theoretical (‘top down’) options and finally resulted in recommendations for the use cases. 
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“No joint approach « Exchange info e Joint approach 
« Exchange info * Common insights * Common insights 
e Coordinated services 


CC | | | u | 
CM1 CM3 CM5 


a 
N CM2 CM4 CM6 


Table 4: Six cooperation model options. 





Discussing the cooperation options more in detail resulted in six elaborated cooperation 
model options - see Table 4. 


CM1 & CM2: In both models, only information is exchanged between the partners. What 
to do with that information is totally up to these stakeholders. They are likely to have more 
information than before and they can use that to optimise their service. 

The difference between CM1 and CM2 is the level of detail of the information that is 
exchanged: situational & operational (traffic conditions, VMS messages active etc.) versus 
tactical & strategic (reduce inflow’ tactic is deployed, strategic goals of government etc.). 


CM3 & CM4: In both models information is shared, and from that information a common 
picture of the current or expected situation is derived. Partners have the same ‘picture’ in 
front of them, however what they do with this information is for each partner to decide for 
itself. 

The difference between CM3 and CM4 again is the level of detail of the information that is 
exchanged: situational & operational versus tactical & strategic. An example of CM4 could 
entail that partners develop common goals and KPIs and individually assess their potential 
to contribute (impact) to this. This cooperation can also be the basis for an impact driven 
business model, where partners are incentivised (rewarded) to contribute to commonly 
agreed goals and KPI's. 


CM5 & CME: In both models information is shared, and from that information a common 
picture of the current situation is developed. Partners have the same ‘picture’ in front of 
them, and in this case, they actually coordinate what actions are taken on both public and 
private side. The idea is that they can strengthen and complement each other instead of 
sending contradictory messages. And they can have positive impact on each others (and/or 
common) goals and KPIs in a coordinated manner. Also, in this case the cooperation can be 
translated into an impact driven business model. 

Once more, the difference between CM5 and CM6 is the kind of information that is 
exchanged: situational & operational versus tactical & strategic. 


Per pilot design is determined which cooperation model fits best. The outcome is shown in 
Table 5 below, and is based on balancing ambition, legacy and learning opportunities for 
the project. 


PS PS 
OO A Copenhagen 


| Optimising network traffic flow | network | Optimising network traffic flow | flow 


Smart destination — 





Table 5: Overview of cooperation models to be tested. 


3.4 Intermediary design 


The various use cases and coordination models each ask for certain roles to be fulfilled 

by stakeholders. The project, therefore, explored the options for an ‘intermediary’: 

a facilitating actor or function for the interaction between public and private service 
providers in delivering traffic management services. This enables truly interactive traffic 
management, the overarching goal of SOCRATES?*, In short, the framework! presented the 
following options for an intermediary: 


e No intermediary: Each public or private service provider arranges its own interactions 

e Multiple public or private intermediaries: Each public or private service provider can 
decide which intermediary service to subscribe to 

e One intermediary for public service providers: public TMC's align on traffic management 
measures, while private service providers operate independently 

e One intermediary ‘trusted party’: Each service provider acts as an integrated part of 
the intermediary (multiple parties (public and private) come together and implement 
different roles of an intermediary. The resulting services are offered as trusted party 
services) 

e One intermediary ‘orchestrator’: Each public or private service provider is connected to 
the intermediary which provides instructions to all services/systems/users. 


As a part of defining the pilot designs the partners specified this concept further into tasks 
and functions, how these could be grouped and how data/information flows should be 
designed. This enabled the partners to organise more detailed discussion on distribution 
of roles between types of stakeholders (public authorities, private service providers and 
others) and how roles can be allocated to the consortium partners. 





1 Report ‘Proposed Cooperation Framework and bottlenecks’, May 2018, Deliverable Activity 2, SOCRATES2.0. 
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Intermediary functions 

Several intermediary functions were identified and described. Based on needed expertise, 
different intermediary functions were clustered, resulting in the following four different 
clusters of intermediary roles: 


Strategy Table 
Network Monitor 
Network Manager 
Assessor 


Each of these intermediary roles is described in general terms and is used as a reference 
for detailed description when applied to specific use cases and cooperation models. 


Strategy Table 

The Strategy Table is the meeting place (counsel, assembly) to establish and monitor 
strategic cooperation between public and private parties. It focuses on joint or coordinated 
approaches for the implementation of use cases and services. Public and private strategic 
goals and roadmaps are brought to the Strategy Table and through a joint process 
promising win-win-win business cases are described. 

Both individual and common goals are identified and translated into measurable KPIs. 
Public and private services with potential impact on the KPIs are identified and generally 
described. The impact of the services to the KPIs is reported regularly to the Strategy Table, 
allowing an agreed period of time to revise performance and achievement of the individual 
and collective goals or KPIs. When necessary and agreed the Strategy Table will also define 
guidelines and principles for ranking and/or rewarding the level of impact delivered by 
public and private parties. 

The Strategy Table is facilitated by a facilitating partner and will have participants with a 
mandate from the public and private parties they represent. 


Network Monitor 

The Network Monitor collects data from road authorities and private data providers and 
determines the common current (and if possible predicted) state for a pre-defined use 
case related network and indicators. In this process the Network Monitor can perform 
data handling services such as quality assessment, data completion and fusion of different 
public and private sources according to use case and business requirements. The Network 
Monitor distributes the network common state to other intermediary roles and other 
agreed parties. 


Network Manager 

The Network Manager combines KPls (desired state of network) with current (or predicted) 
network state and defines the problem statement. Furthermore, he identifies potential 
effective measures to solve the problem based on available public and private services. The 
Network Manager distributes services requests and receives feedback on the performance 
of the deployed services and uses it to improve the corresponding scenario. 


Assessor 

The Assessor collects, validates and reports the impacts (value) of public and private 
services to the defined KPIs. If defined, the Assessor can also be responsible for 
implementation and management of a reward system based on the reported impact of 
services to specific KPIs. The Assessor is most necessary in impact driven cooperation 
models. 


Combinations of cooperation model and intermediary design 

The types of and need for intermediary roles is one of the elements to be studied within 
SOCRATES?*. With this objective in mind it is valuable to experiment different combinations 
of cooperation models and intermediary roles over the pilot sites and use cases. After all, 
one of the SOCRATES? main learning objectives is to gain insights on how to organise the 
collaboration between public and private parties, and what key elements are necessary to 
assure scalability and success of the use cases. 


Also, note that not all intermediary roles are necessary in all of the cooperation models. 
Where the focus of cooperation is based only on the exchange of information (CM1 

and CM2) some intermediary roles do not necessarily add value to the use case. For a 
cooperation based on creating common data insights only (CM3 and CM4) the Network 
monitor seems necessary and an Assessor would also be beneficial. Also, not each task per 
role needs to be deployed. The most advanced and complex cooperation models require 
all four intermediary roles. 


Definition 


Need for a Network Manager? 
Need for an Assessor? 


* Yet to be considered for project evaluation. 





Table 6: Characteristics of the different cooperation models. 
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4. SPECIFICATION OF THE 
DATA INTERFACE: TMEX 





B RAN 


SOCRATES? is based on the strategy as developed by the TM? initiative?. One of the 
objectives of SOCRATES? is to define a prototype TMex protocol and to test this in a large 
scale, operational environment. TMex covers all tactical information (including the level 
of smart routes) to be exchanged between traffic centres and back offices, both for traffic 
information and for traffic management information. TMex is based on European or 
regional developed standards based on DATEX Il. 


The future cooperation framework leads to a new concept and functional design. The 
concept describes the data driven collaboration function that transforms TM1.0 into TM2.0. 
All partners identify how they use their (upgraded) products in order to fulfil parts of the 
value chain within this concept. The outcome is processed in the functional design of the 
pilots. Based on this, the TMex interface is specified, such that the same interface can and 
will be used by all partners in the test-site(s). The TMex interface provides the interface 
between traffic centres and intermediaries and between intermediaries and back offices. 
TMex architecture is based on the requirements for data exchange between service 
providers and traffic centres. 


TMex interface 


Traffic centers Service Providers 
strategic routes 


Existing data formats: es Sensoris 
RER z TPEG 
[EU] DATEX II 


[NL] VLOG3 
[NL] IVERA4 
[NL] DVM-Exchange 


[DK] RSMP 
[DK] RSMP++ 


[DE] OCIT 


<< TLC >> 
IVERA, RSMP, OCIT etc. 


<< C-ITS >> 
DENM, IVI, CAM etc. 


Out of TMex' scope 





Figure 5: Overall architecture of the TMex interface positioning in the SOCRATES? context. 





? http://tm20.org/ 
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TMex in SOCRATES? will be flexible and aligned across the four pilots to make sure that 
the cross-border interoperability is ensured to allow a future proof implementation. The 
project will deliver the proposals for the DATEXII standards, new extensions for traffic 
management plans and new elements in such a way that it can be discussed in the 
according standardisation bodies in Europe. 


Prototype TMex specification 

As a part of Activity 3 the project delivered a first TMex specification based on assumptions, 
ideas and requirements from SOCRATES?, Also, the project elaborated the steps to take, 
aimed at actual implementation in order to achieve a final specification. 


TMex is not a protocol as such, but a collection of APIs within a catalogue using a 
standardized approach. The TMex interface is the user shell around the TMex API catalogue 
and offers the first stop to go when looking for SOCRATES? related traffic data and 
information. The API catalogue shall be a searchable, web-based portal. 


We have seen that traffic management plans, routes and geo-fences are missing in DATEX 
Il. Besides the API catalogue and existing DATEX II data formats, within SOCRATES? the 
DATEX Il extension for traffic management plans, routes and geo-fencing will be part of 
the deliverables. The project will take a layered approach to deliver these data formats. 
The routes are intended to be used for the strategic routes from road authority to service 
provider and for smart routes from service provider to road authority. These routes form 
the base for almost all traffic management plans and as no standard has been defined yet, 
SOCRATES? will establish this standard. 


The project identified data sources that are part of the use cases and pilot sites and 
determined what data sources should be handled by TMex and what data sources 
shouldn't. TMex will cover most of the data exchange requirements within the use cases 
and pilot sites in SOCRATES?“, however for every situation the data exchange situation and 
possibilities should be evaluated and the most practicable approach should be chosen. 
The DATEX II community will be involved in order to get an aligned proposal that covers the 
SOCRATES? requirements and can be used throughout the protocol. 
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5. PILOT DESIGNS 
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5.1 Functional design 


A functional design is a detailed description of pilot set-ups. A core element of it is a 
functional architecture, providing blueprints for the pilot sites to support planning and 
implementation. 


Functional designs were elaborated by individual teams for each pilot deployment. They 
were asked to describe the designs in a common template, consisting of the following 
items: 


1. Context & Mission of pilot deployment 
1.1 Local context 
1.2 Existing services 
1.3 Available data 
1.4 Problem statement 
1.5 Mission of use case 
2. Existing services for pilot deployment 
2.1 Identification of use case levels 
2.2 System overview (including system components & relations) 
2.3 Roles & actors 
2.4 Cooperation model 
3. SOCRATES? services for pilot deployment 
3.1. System overview (including system components & relations) 
3.2. Cooperation model 
3.3. Roles 
3.4. Intermediary 
3.5. Actors 
3.6. Pre-conditions, post-conditions & sequence diagram 


These items were elaborated step-by-step within the individual teams. By reflecting the 
results in regular meetings with the entire project team, a consistent and a common 
understanding for each pilot description could be reached, even if all pilot deployments 


eventually show different characteristics. 


Major elements of the functional design descriptions are explained below. 
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5.2 System overview 


One major element of the functional design descriptions was the ‘system overview’, 
showing the interactions between the various elements, actors, data streams and 
interfaces. Usually, two system overviews were created: one for the existing conditions and 
one for the envisioned pilot design. 


An example for such a system overview is shown below, here for the pilot deployment 
‘Optimising network traffic flow, Amsterdam’. 


STRATEGIC 


C Collective goals 


TACTICAL 






Public common goals 
(‘Regelstrategie’) 









Private Goals 















Public common approach 
(‘Regeltactieken / regelaanpak’) 


'Regel' strategy, 
Reference cadre 


OPERATIONAL Routing 


algorithm 





Public common data 

Response plans À . E A 
+ algorithm DVM-X aggregation and distribution Personal 

between TMC (NDW) route advice 


Actuators Actuators 


berate Actual Actual vehicles 
K Traffic State Aggregation data Traffic State = 
Sensors Sensors 


Travel times, OD, 
Followed routes, events 





Volumes, Events, 


SITUATIONAL speed etc 
Figure 6: System overview, pilot deployment 'Optimising network traffic flow, Amsterdam’, existing conditions. 
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en nnn * Setup KPI's a or een 
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+ Configuration of goals, 
KPI and toolbox 
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+ Measure impact, 


I 

I 

1 
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- validation, reward, I 
I 

I 

1 

1 
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I 

I 

1 

I 

I 

1 * Data fusion ie 
I + Data Completion (ki 

1 * Common current state 

I 
1 
I 


Prediction 


data archiving 


Network Manager 
+ Problem state 
* Strategy identification and 
‘Regel' strategy, orchestration Merge Private and 
Reference cadre + Distribution of SR Common goals 
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OPERATIONAL Routing 
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Response plans 
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route advice 


LEGEND 


Actuators Actuators 
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Figure 7: System overview, pilot deployment 'Optimising network traffic flow, Amsterdam’, pilot design conditions. 
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5.3 Description of intermediary roles 


Comparing Figures 6 and 7, it is obvious that exchange between road authorities (elements 
shown in blue) and the service providers (elements shown in green) are mainly facilitated 
by the intermediary (elements shown in red). 


There are four possible roles of the intermediary which have been introduced before: 


Strategy Table 
Network Monitor 
Network Manager 
Assessor 


The corresponding roles were further described for each pilot deployment, including 
aspects for each role such as: 


Assignment of a main partner as a design leader 
Assignment of supporting partners 

Objective 

Approach and timeline 

Interfaces and input/output 

Risks and mitigation 


The role descriptions were again documented in common templates, as shown in Figure 8. 


SOCRATES?20 


<<function>> <<part of role>> FAS MES GREEN 
<<responsible partner>> <<supporting partner(s)>> 


<<description of function>> 


<<description of interfaces and output/input>> 








Figure 8: Template for description of intermediary roles. 
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5.4 Partner distribution 


As a final step of the pilot design, a final distribution of partners per role and per pilot 
deployment was agreed upon. 


Potential roles include the four intermediary roles (see above) as well as specific actors 
such as service providers, traffic managers and data providers. These roles are described in 
Table 7. 


Strategy Table Create win-win-win / Align public and private goals / Define KPI's / 
Setup toolbox / Monitor (8 redefine) strategic goals and KPI's 


Network Monitor Collect aggregated data from public and private data providers / 
Fuse data / Predict state of the network / Assess data quality / 
Respect data agreements 


Network Manager Configuration of KPI's / Create problem state / Identify an effective 
scenario to solve the problem / Send service requests / Evaluate and 
improve scenario 


Assessor Validate partner impact / Report on impact and KPI / Virtual rewarding / 
Data archiving 


End user Private service provider Receive and assess service requests / Activate routes / Measure own 
impact and inform Assessor 


Public traffic manager Receive and assess service requests / Activate routes / Measure own 
impact and inform Assessor 





Table 7: Description of intermediary roles. 


This partner distribution forms the commitment of individual partners when continuing 
with the realisation of the pilots, as elaborated in Activities 4, 5, 6, and 7. 


There are different levels of partner commitments, such as: 


e Lead partner: one per role 
a Responsive to the role 
= Specify / organise the role 
= Monitor timely performance of all tasks 
sm Contact for transition manager 
= Perform one or more tasks 
e Supporting partner: 
= Support the lead in specifying and organising the role 
m Perform one or more tasks 
e Participating partner: 
m= Perform one or more specific tasks within a role 
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The partner distributions were again documented in common templates, as shown below. 


Strategy Table 


Network Monitor 
Network Manager 
Assessor 
role | Participating Partners | 
End user Private SP's 
Public RA's 





Table 8: Template for partner participation per pilot deployment. 


5.5 Factsheets on the pilot designs 


Essential information on the design of each pilot deployment in SOCRATES? has been 
compiled as factsheets, and are available as a seperate annex of this report. The factsheets 
reflect the following: 


What problem is addressed with this use case? 

When will this use case be successful? What goals do we want to achieve? 
Expected win-win-win 

What cooperation model is being tested? 

What intermediary roles are defined? 

How does the service work? 

End user services will be provided by ... 
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6.1 Ex-ante evaluation 


The project plan agreed upon the accomplishment of an ex-ante evaluation. This ex- 
ante evaluation aims to concretise the results formulated by the partners. The ex-ante 
evaluation can also be used as a framework for the evaluation of the SOCRATES? pilots. 


The ex-ante evaluation was carried out in two steps. In the first step, the evaluation 
framework defines the aspects to research. Possible research questions that were 
formulated in different documents, were collected and sorted in the updated framework. 

In the second step, each of the research aspects is elaborated and the upfront expectations 
(expected outcomes/effects) are presented. 


As the necessary plans for the pilot sites were still being developed (among others the 
selection of use cases), some upfront expectations are formulated in terms of ‘insight 
into ... (qualitative description). The ex-ante evaluation will not extendedly elaborate on 
the research aspect ‘technical conduct’ because this aspect is in principal up to the service 
providers. Furthermore, this evaluation does not include expected outcomes / effects on 
the safety of road users in relation to the use of devices while driving. 


The evaluation framework exists of six research aspects, as shown in Figure 9. 


User acceptance 





Participants 
"A: Cooperation Satisfaction road users 
AA (public/private) Follow-up behavior 





participants 


Gm Traffic 
effectiveness 





Cooperation on strategic level 


Cooperation on tactical level EAN 
Traffic distribution over 


Cooperation model road network 


Role of road operators Anticipation on traffic 


situations 


A Applicability to 


comparable situations 





Scalability 
New business cases 


[n Data management 
and quality 


Required data 





x Technical conduct 





Data exchange 
Reliability data 
Algorithms 


Technical stability 


Figure 9: Evaluation framework SOCRATES. 
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In Activity 2, the partners of SOCRATES? assembled a shared vision on interactive traffic 
management. The shared vision provides the main objectives, key research questions 
and leading principles on a strategic level. The vision elaborates along four elements and 
gives guidance to define use cases and the scope of tests to be performed at the various 
pilot sites. The four elements are (1) the customer; (2) community; (3) technology; and (4) 
cooperation. 


The ex-ante evaluation focusses on the four elements with the following research aspects. 
The ex-ante research questions are connected with the use cases and four elements of 
SOCRATES?*, The findings of the evaluation will be elaborated from the perspective of the 
goals of SOCRATES?° and will provide an answer if the objectives are achieved and to what 
extent. 


The four elements of SOCRATES?” | Ex-ante research aspects 

Customer User acceptance (Participants - Satisfaction road users - Follow-up 
behaviour participants). 

Community Traffic effectiveness (Traffic distribution over road network - Anticipation 
on traffic situations). 


Technology This is mostly the necessary intermediary technology (Fusion, 
completion, prediction, cop, service request management). 
Technical applicability and scalability of the complete chain of the 
cooperation framework. 
Data management and quality (Required data/available data - Data 
exchange, also TMex - Reliability data - Algorithms, fusion, completion, 
prediction). 





Cooperation Cooperation between governments and private parties (Cooperation on 
strategic level- Cooperation on tactical level - Cooperation model - Role of 
road operators). 

This is mostly the necessary intermediary functions and responsibilities 
and deriving win-win-win. 
Applicability to comparable situations (Scalability - New business cases). 


Table 9: SOCRATES? elements and evaluation research aspects. 
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6.2 Evaluation approach 


Goal of the evaluation is to provide answers to the evaluation/research questions by 
means of collecting, analysing and evaluating measured data. And it will provide proof of 
the actual operators of the SOCRATES? concept. The ex-post results are compared with 
the expectations from the ex-ante to judge the actual performance and impact against the 
expected one’. 


The project evaluates the results and learning experiences in four pilot sites and for 
different use cases. To gain in-depth learning experiences and underpin statements, a 
comparison analysis is executed between the four pilot sites and different use-cases (cross 
pilot level). 


The project considers a flexible research approach as essential, because the evaluation 
depends on various choices within the development process. Such as the design of the 
four pilots and use cases, the selection of participants, the logging of data, the choice of 
cooperation model, etc. 


Goals Socrates?° Level 1 Evaluation of scalability 


Evaluation of maturity on the basis of four elements of Socrates20: 


2.0 
IS a Customer, Community, Technology and Cooperation 


Cross 'pilot' Level 3 Comparative analysis at cross-pilot level 


Data collection and depth analysis at the single 


Use Case Level 4 ; 4 
use case / pilot site level 





Technical 


Organisational Functional 5 i y 
p A = A technical conduct 
cooperation user acceptance’ and Anddars management 
(public / private) ‘traffic effectiveness’ E 


and quality’ 


Figure 10: SOCRATES2° evaluation principles. 


The performance measured on organisational, functional and technical level will be 
combined in a synthesis to allow these individual performance analyses to learn from each 
other. This means that the results of the performances are the basis level of evaluation 
done. Within the synthesis these results will be connected together and thus allow us to 
look at what SOCRATES?” has realised, how much of the set objectives and goals have been 
met as well as answering the questions mentioned below. 
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For this synthesis step we will built on the following aspects as explained in Figure 10. 


e Level 1: This level is based on the two overarching goals from SOCRATES?” that will be 
reported upon. 


Goal 1: To design, operate and evaluate new and extended traffic management 
measures and mobile/in-car services for road users; based on a close cooperation 
of road authorities, service providers and car industries. 

Goal 2: To design, operate and evaluate a cooperation framework (at strategic, 
tactical and operational level) for interactive traffic management by road 
authorities, service providers and car industries. 


e Level 2: Following these goals we will evaluate the maturity of the four elements from 
SOCRATES? as defined in the Socrates Vision, Activity 2. 

e Level 3: A comparative analysis at cross-pilot level. 

e Level 4: This is the use case level per pilot - where most of the performance results will 
be used directly. This will be related to the goal of the use cases in the pilot sites as well 
as the stated success factors. 
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7. CONCLUSION 
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7.1 What has been achieved in Activity 3? 


Based on the common ‘Framework for cooperation in traffic management‘, defined in 
Activity 2, the common approach was specified for the four pilots in Activity 3. This included 
an explicit concept for interactive traffic management on a tactical level, eventually 
resulting in functional designs for each envisioned pilot site and use case. 


Besides the (functional) designs of the pilot sites, Activity 3 also resulted in presenting 
a progressive guideline for stakeholders engaged in (similar) deployment projects for 
interactive traffic management. 


To realise the pilot designs dedicated Focus Groups were established that elaborated on 
some organisational, functional and technical aspects, touching on the roles of partners 
and their products and services. The Focus Group(s) also elaborated on the interfaces 
between those products and services. As an outcome from the mentioned Focus Groups, 
some sub-steps could be identified when it comes to preparing pilot deployments. The sub- 
steps form the milestones of the aforementioned guideline. The concept of this guideline is 
shown in the figure below. 


Make an Specify a 
a Select a a 
inventory of the cooperation 
: : use case 
pilot site model 


Provide a 
functional 
design 


Specify a data Specify an 
interface intermediary 





Next steps: 
Technical design 


x 


Plan the 


evaluation 





DEPLOYMENT OF 
INTERACTIVE 
TRAFFIC 
MANAGEMENT 


Figure 11: Preliminary step-by-step plan to the deployment of interactive traffic management. 
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7.2 | Recommendations and learnings on specific elements of Activity 3 





We believe that the approach taken in Activity 3 is a role-model when preparing 

deployment projects for interactive traffic management, not only in SOCRATES?°. The 
processes and outcomes described in the previous chapters form the milestones of a 
guideline, which will lead to successful deployment of interactive traffic management. 


In SOCRATES? there will be many pilot deployments, which all have different 
characteristics. On the other hand, a common framework and approach behind each pilot 
will help find some consistency and comparability among all deployments, eventually also 
supporting interoperability and scalability. 


In the work of Activity 3, some elements have been specified to establish such a common 
approach. Looking at these elements, the following success factors and recommendations 
were identified: 


Coordination models 

As introduced in Activity 2, cooperation models describe the level and intensity of 
cooperation of different partners. Based on partner inputs and pilot site conditions, the 
cooperation models have been elaborated in more detail and clustered in six types of 
models. 


This way it was possible to find a common understanding on the preconditions and 
impacts of each cooperation model. The cooperation models have been described in a 
universal way, allowing to adopt them in any deployment environment. 


In the present stage of SOCRATES?*, it was important to finally decide which cooperation 
model will be applied per deployment, and to prepare the partners to take on 
corresponding roles within the chosen cooperation context. 


As an important learning from the pilot deployments, we would like to explore how the 
different cooperation models work out in practice, and which models meet the overarching 
goals best. 


Intermediary 

Intermediaries are the prerequisite to facilitate the envisioned data cooperation, building a 
data bridge between road authorities and the service providers, and being integrated into 
data eco-systems which are already in place. 


Activity 2 has already laid out some basic concepts for Intermediaries. Based on this, 
Activity 3 was able to deepen and expand on the functionalities of an Intermediary. In 
particular, different options how to place the Intermediary within an existing data eco- 
system, as well as potential roles of an Intermediary have been defined. 


These definitions are also described in a universal way, to be potentially re-used in other 
deployment environments. 
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As for the cooperation models, we expect to learn from the pilot deployments, how the 
different Intermediary types work out in practice. 


As each Intermediary type has a different impact on the cooperation, it is essential to relate 
the choice of an Intermediary type to the choice of cooperation models and use cases. 


Eventually, for each deployment within SOCRATES?*, a relation of a specific uses case, 
cooperation model and intermediary type needs to be defined.? Such relations are 
fundamental decisions of Activity 3, setting the tactical stage for the upcoming pilot 
realisations. 


TMex 

We expect that big amounts of data of different kind will be exchanged within the pilot 
deployments. To handle that exchange in an efficient and interoperable manner, a 
commonly agreed data exchange concept seems to be promising. 


In SOCRATES?®, the TMex concept was developed for this reason. TMex describes exchange 
concepts regarding data interfaces, data protocols and data platforms. These concepts 
should be applied for all deployments, regardless their specific data environments. 


Of course, the concrete data eco-systems will be defined by each deployment individually. 
However, TMex is understood as a minimum, overarching solution, which is adoptable 
and expandable to any deployment. This way, the TMex approach will allow scalability and 
transferability, also beyond the SOCRATES?” project. 


An important aspect of TMex at this stage is to allow flexibility for different data domains 
and to different data actors. An important building block for this is the TMex API catalogue, 
which can be seen as a modular system, providing a 'single access point' for relevant data 
sets. 


Another important aspect is to build on existing approaches, such as DATEX ll, to avoid ‘re- 
inventing the wheel’. 


Pilot designs 

As the pilot deployments are expected to be realised and tested very soon, the pilot 
designs of Activity 3 aimed to provide a good starting point to build on during the 
subsequent Activities 4, 5, 6, and 7. 


This way, each pilot team is provided with a basic design to be further elaborated in their 
individual pilot settings. In particular, the provided functional designs will be translated into 
a complete architecture (information, application and technical architecture). 





3 In the internal SOCRATES? wording, each deployment was named as 'Use Case/Cooperation Model/Intermediary combination’. 
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One important feature of the presented pilot designs are the 'system overviews', 
elaborated for each pilot deployment and showing the interactions between the various 
elements, actors, data streams and interfaces. As basic structures of the pilots are defined 
here, the pilot teams can quickly start to detail and to implement the individual elements. 


At the present stage of SOCRATES?", it was important to specify the pilot details in a 
sufficient, but not too extensive manner: 


e The basic design elements, such as the mentioned system overviews, should make sure 
that the underlying tactical decisions (e.g. on the Cooperation Models) are reflected well 
in a technical context. Further, a common understanding on potential functions and 
roles among project partners is supported this way. 

e On the other hand, the presented design elements allow enough room for specifications 
to be made in the individual pilot settings. 


Another prerequisite is to assign specific partners to different responsibilities and roles of 
the upcoming pilots. This way, the coordination tasks of the individual pilots will be eased 
by already having clear partner commitments and organisational structures. 


7.3 What's new in the pilot designs? 
In short, we can summarize the new elements in the pilot designs as follows: 


Sharing public €: private strategy and goals, common KPI's (Strategy Table) 
Exchanging public & private data and information (Network Monitor) 

A joint ‘current (and predicted) state’ on the network (Network Monitor) 

A joint ‘current state’ on roadworks (user feedback and service provider data is fused 
with roadworks information from the road authority) (Network Monitor) 

e Public / private network management (Network Manager) 

e Request for network management services to service providers (Network Manager) 
e Looking for an ‘impact driven’ business model (Assessor) 


7.4 Recommendations and learnings from the approach 





There are also some recommendations on the general approach. A basic concept was to 
combine the technical design work (in individual teams) with an overarching support of all 
partners (by providing harmonized tools and enabling regular exchange). As a result, our 
approach was based on the following success factors and recommendations: 


e As the topics may become quite complex, it is useful to break down the approach into 


sub-steps. In SOCRATES?", focus groups were installed and various sub-deliverables 
were produced, which in total form the ‘big picture’. 
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e To reach the final designs, a step-by-step and iterative elaboration is recommended. 
This way, there is an evolution from ‘rough’ to ‘detailed’, allowing some flexibility and 
agility during the design process. 

e Toachieve a consensus on high-level agreements (e.g. on a suitable cooperation model), 
parallel top-down and bottom-up approaches seem promising, taking into account both 
overarching and individual perspectives. 

e Aharmonized approach to describe the pilot set-ups will help to find consistency and a 
common understanding on the approach. To support this, general templates to gather 
information (e.g. functional design templates) and a common wording to describe 
certain aspects (e.g. for the intermediary roles) were used. In a later stage, these general 
descriptions can be further detailed when applied to specific deployments. 

e Even if a harmonised design approach is recommended across all pilots, it is still crucial 
to consider and respect local conditions as well as individual perspectives of partners. 
This has been achieved by an initial pilot site inventory and reflected as a pre-condition 
for each pilot design. 

e Many details were elaborated in individual groups for each pilot deployment. However, 
regular reflection of the results with the entire project team is helpful, to track the 
individual progress and to learn from each others experiences. 

e Finally, regular exchange with the overarching project structure (Project Management 
Meetings, Steering Group meetings) helps to make sure that common project goals are 
met during the Activity runtime. 





7.5 Next steps: technical design and validation of the pilot designs 


Now that the pilot designs are ready, the next step in the SOCRATES?! project is to validate 
the pilot designs in the four pilot sites Amsterdam, Antwerp, Copenhagen and Munich 
(Activity 4, 5, 6, and 7). To do so, the functional designs need to be translated into technical 
designs and (changes to the) sub-systems need to be realised. Activity 4, 5, 6, and 7 will 
also involve the recruitment of beta users, who will use the modified end-user application. 
The pilot designs will be evaluated in Activity 8. The results will be used to update the 
framework and complete the guideline (Activity 9). 
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